A. Field of the invention
This invention relates to data processing systems, and more particularly to remote method invocations on remote servers. Even more specifically, this invention relates to a method and system for identifying remote methods on a server machine using hash values.
B. Related Art
Distributed systems typically comprise multiple machines, such as computers and related peripheral devices, connected in a network, for example, a Local Area Networks (LAN), Wide Area Network (WAN), or the Internet. Distributed systems generally require that computational entities (e.g., applications, programs, applets, etc.) running in different address spaces, potentially on different machines, be able to communicate.
For a basic communication mechanism, distributed object oriented systems utilize a Remote Procedure Call (RPC) mechanism referred to as Remote Method Invocation (RMI). RMI facilitates application-level communication between "objects" residing in different address spaces. In object oriented systems, a "class" provides a template for the creation of "objects" (which represent items or instances manipulated by the system) having characteristics of that class. The term template denotes that the objects (i.e., data items) in each class, share certain characteristics or attributes determined by the class such as its methods. Objects are typically created dynamically during system operation. Methods associated with a class are generally invoked (i.e., caused to operate) on the objects of the same class.
RMI is the action of invoking a method of a remote object. In response to the invocation of a method of a remote object using RMI, a lower level communications process causes the invoked method to be executed on the remote object.
The Java.TM. runtime system, which is designed to implement applications written in the Java.TM. object oriented programming language, supports a specific Java.TM. RMI Application Program Interface (API). This API is explained in, for example, a document entitled "Remote Method Invocation Specification," Sun Microsystems, Inc. (1997), which is available via universal resource locator(URL)http://www.javasoft.com/products/jdk/1.1/docs/guide/rmi/spec/r miTOC.doc.html,and is incorporated herein by reference. The Java.TM. language is described in many texts, including one that is entitled "The Java Language Specification" by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996. Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Java RMI assumes a homogeneous environment of the specialized Java runtime system, and therefore Java RMI takes advantage of a specialized object model for the Java language whenever possible. In the Java.TM. distributed object model, a remote object is one that has methods that can be invoked from another runtime system, potentially on a different machine. An object of this type is described by one or more remote interfaces code written in the Java language that specify the methods of the remote object.
The Java runtime system keeps track of all remote objects referenced by computational entities executing through a local virtual machine (VM). The Java.TM. VM (JVM) is an abstract computing machine of the runtime system that receives instructions from programs in the form of bytecodes and that interprets these bytecodes by dynamically converting them into a form for execution, such as object code, and executing them. The JVM is described in detail in a text entitled "The Java Virtual Machine Specification" by Tim Lindholm and Frank Yellin, Addison Wesley, 1996.
In Java RMI, a client, while processing a program, can remotely initiate processing by a server computer of methods in connection with certain "parameter" information provided by the client. After the server has processed the procedure, it will provide results of its processing to the client, which the client may thereafter use in its processing operations. Typically in such RMI calls, the client will make use of a local "stub" which, when called, transfers the request to the server which implements the particular method, obtains the results and provides them back to the client.
Conventionally, when a client calls a method on a remote object containing a list of methods, the method is identified by a string name or a sequence number identifying the selected method. However, identifying a method by its string name can create false identification of a remote method because the remote object may have more than one method with the same string name. Such methods are said to be "overloaded." Although methods may have the same string name, overloaded methods with duplicate same string names typically take different parameter types. For instance, suppose a remote object, using the Java programming language, has the following two methods:
public interface Directory PA1 public interface Directory PA1 1. lookupPhone PA1 2. storePhone PA1 public interface Directory PA1 1. lookupAddress PA1 2. lookupPhone PA1 3. storeAddress PA1 4. storePhone
{PhoneNumber lookupPhone(String name); PhoneNumber lookupPhone(Person person)} PA2 {PhoneNumber lookupPhone(String name); void storePhone(String name); PA2 PhoneNumber phone);} PA2 {PhoneNumber lookupPhone(String name); PA2 void storePhone(String name); PA2 PhoneNumber phone); PA2 Address lookupAddress(String name); PA2 void storeAddress(String name, Address addr);}
If a client seeks to invoke one of these two methods, the string name "lookupPhone" alone does not enable the remote object to determine the correct method to be invoked because more than one method with that name exist.
Another conventional approach for identifying a remote method is to put the methods in alphabetical order and number them. Suppose a remote object implements the following two methods:
The numbering of the methods may be represented as follows:
When a client wants to invoke a method, it simply sends the number corresponding to the method in the method invocation instruction. If, however, new methods are added to the remote object such that it appears as follows:
the new numbering of the methods would be:
Hence, the numbers corresponding to each method have changed. Thus, existing clients that continue to use old stubs using the old numbering would invoke the wrong methods.
Accordingly, it is desirable to provide a system that uniquely identifies the methods of remote objects for RMI.